feat(ci): automate releases with changesets#4
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds Changesets-based release automation: adds Changes
Sequence DiagramsequenceDiagram
participant Dev as Developer
participant GH as GitHub
participant CI as GitHub Actions
participant Repo as Git Repository
participant NPM as npm Registry
participant Rel as GitHub Releases
Dev->>GH: Open PR with code + `.changeset` entry
GH->>CI: Trigger PR checks
CI->>CI: Run `pnpm changeset status` (validate)
CI->>CI: Build/test/lint
CI-->>GH: Report status
Dev->>GH: Merge to `main`
GH->>CI: Trigger publish workflow
CI->>CI: Run `pnpm changeset version` (bump versions, update changelog)
CI->>Repo: Commit version bump and changelog
CI->>Repo: Push commit and tag
CI->>NPM: Run `pnpm release` (publish packages)
CI->>Rel: Create GitHub release
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
.github/workflows/publish.yml (2)
85-85: Avoidgit add .in release automation.Staging everything can accidentally include unrelated artifacts from prior steps.
🧹 Proposed safer staging
- git add . + git add -A package.json CHANGELOG.md .changeset + [ -f pnpm-lock.yaml ] && git add pnpm-lock.yaml || true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish.yml at line 85, Replace the unsafe "git add ." in the publish workflow with explicit, narrow staging: change the command in the job step that currently runs "git add ." to add only the specific release artifacts (for example use "git add <artifact-paths>" or a targeted pattern), or if necessary use "git add -u" to only stage tracked changes; ensure the step references the exact files produced by the release (e.g., built output, changelog, package metadata) instead of adding all files.
95-101: Make tag/release creation rerun-safe.Without guards, reruns fail when the tag or GitHub release already exists. The current workflow at lines 95-101 directly creates a tag and release without checking for existence first.
♻️ Proposed idempotent release step
- name: Create GitHub release if: steps.version.outputs.changed == 'true' run: | VERSION="v${{ steps.version.outputs.version }}" - git tag $VERSION - git push origin $VERSION - gh release create $VERSION --generate-notes --title "$VERSION" + if ! git rev-parse "$VERSION" >/dev/null 2>&1; then + git tag "$VERSION" + git push origin "$VERSION" + fi + gh release view "$VERSION" >/dev/null 2>&1 || \ + gh release create "$VERSION" --generate-notes --title "$VERSION"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish.yml around lines 95 - 101, The release step ("Create GitHub release") must be made rerun-safe by checking for existing tag and release before creating them: use the VERSION variable and guard the git tag / git push and the gh release create commands by first detecting if the tag already exists (e.g., via git rev-parse --verify or git ls-remote origin refs/tags/$VERSION) and skip tagging/pushing when present, and detect if the GitHub release exists with gh release view "$VERSION" and only run gh release create $VERSION --generate-notes --title "$VERSION" when it does not; update the commands in that step so reruns do not fail when the tag or release already exists.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish.yml:
- Line 13: The workflow currently pushes the version-bump "chore: release"
commit before running the npm publish step, which can leave main updated but
unpublished if publish fails; to fix this, reorder and gate steps so the npm
publish job/step runs and succeeds before the release commit is created/pushed
(move the 'npm publish' step to occur prior to the "push release commit" step
and/or make the push depend on the publish job result), and remove or change the
"!contains(github.event.head_commit.message, 'chore: release')" condition so the
push step is only executed after a successful publish; reference the 'npm
publish' step and the push step that currently checks
"!contains(github.event.head_commit.message, 'chore: release')" when making
these changes.
In `@CONTRIBUTING.md`:
- Around line 7-9: Update the CONTRIBUTING.md entry for the "pnpm dev" command
to accurately describe its behavior: replace the current "build dist"
description with a note that "pnpm dev" runs the development/watch mode and
continuously rebuilds on file changes (i.e., starts a dev server/watch process
rather than doing a one-time build). Ensure the line referencing the command
"pnpm dev" is updated to mention continuous rebuilds/watch mode so readers
understand it's not a single build.
- Around line 61-63: The release flow text is outdated: replace the sentence
that says a CI pipeline "opens a **'Version Packages'** PR that bumps the
version and generates `CHANGELOG.md`" with a short description of the current
behavior (the publish workflow now performs a direct version-bump commit on main
and publishes to npm on merge), remove the mention of the "Version Packages" PR,
and ensure the updated wording explains that merging to main triggers an
automatic version bump, CHANGELOG generation and publish.
---
Nitpick comments:
In @.github/workflows/publish.yml:
- Line 85: Replace the unsafe "git add ." in the publish workflow with explicit,
narrow staging: change the command in the job step that currently runs "git add
." to add only the specific release artifacts (for example use "git add
<artifact-paths>" or a targeted pattern), or if necessary use "git add -u" to
only stage tracked changes; ensure the step references the exact files produced
by the release (e.g., built output, changelog, package metadata) instead of
adding all files.
- Around line 95-101: The release step ("Create GitHub release") must be made
rerun-safe by checking for existing tag and release before creating them: use
the VERSION variable and guard the git tag / git push and the gh release create
commands by first detecting if the tag already exists (e.g., via git rev-parse
--verify or git ls-remote origin refs/tags/$VERSION) and skip tagging/pushing
when present, and detect if the GitHub release exists with gh release view
"$VERSION" and only run gh release create $VERSION --generate-notes --title
"$VERSION" when it does not; update the commands in that step so reruns do not
fail when the tag or release already exists.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.changeset/config.json.github/workflows/ci.yml.github/workflows/publish.ymlCONTRIBUTING.mdREADME.mdpackage.json
- Add @changesets/cli and @changesets/changelog-github - Add .changeset/config.json for single-package setup - Add changeset check to CI (pnpm changeset status --since base branch) - Replace changesets/action PR flow with direct version bump commit on main - Add CONTRIBUTING.md with PR guide and changeset instructions
Reorder publish pipeline steps so npm publish runs before the version bump is pushed to main — avoids leaving main updated but unpublished on publish failure. Also update CONTRIBUTING.md to fix outdated command description and release flow wording.
rkovalov
force-pushed
the
chore/semantic-release
branch
from
fe97f38 to
3ee3f37
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CONTRIBUTING.md`:
- Line 27: The two unlabeled fenced code blocks used for examples (the
triple-backtick blocks showing the change type options and the commit message
examples) are triggering markdownlint MD040; update each backtick fence to
include a language identifier such as text (e.g., replace ``` with ```text for
both the first example block and the second commit-example block) so linting
recognizes them as plain text code blocks while preserving the existing content.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
CONTRIBUTING.md (1)
34-34: Optional: Consider "brief" for consistency.The phrase "short description" is clear, though "brief description" is a stylistic alternative if you prefer more formal tone.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CONTRIBUTING.md` at line 34, Replace the phrase "short description" in the sentence that begins "Pick the bump type, write a short description of what changed and why (this becomes the CHANGELOG entry), then commit the generated `.changeset/*.md` file with your PR." with "brief description" for stylistic consistency, so the line reads "write a brief description of what changed and why" while keeping the surrounding text and `.changeset/*.md` reference unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@CONTRIBUTING.md`:
- Line 34: Replace the phrase "short description" in the sentence that begins
"Pick the bump type, write a short description of what changed and why (this
becomes the CHANGELOG entry), then commit the generated `.changeset/*.md` file
with your PR." with "brief description" for stylistic consistency, so the line
reads "write a brief description of what changed and why" while keeping the
surrounding text and `.changeset/*.md` reference unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Documentation
Chores